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PREFACE 


This  paper  was  prepared  in  support  of  IDA  subtask  “Global  Command  and  Control 
System  Lessons  Learned.”  The  primary  task,  “Evolutionary  Acquisition  Strategy  and  Planning,” 
was  sponsored  by  the  Office  of  the  Assistant  Secretary  of  Defense  for  Command,  Control, 
Computers,  and  Intelligence  (OASD/C3I).  Technical  oversight  for  this  study  was  carried  out  by 
Ms.  Christine  Condon  of  OASD/C3I. 

The  authors  greatly  appreciate  the  helpful  comments  and  assistance  received  during  the 
development  of  this  paper.  In  addition  to  the  more  than  fifty  individuals  interviewed,  the  authors 
wish  to  thank  Drs.  Robert  Anthony  and  Victor  Utgoff  for  their  gracious  and  insightful  comments, 
Ms.  Eileen  Doherty  for  her  editing  of  this  paper,  and  Ms.  Olga  Alvarado  and  Ms.  Barbara 
Varvaglione  for  their  supporting  efforts. 

Finally,  the  authors  note  that  the  judgments  expressed  in  this  paper  are  their  own  and  are 
not  necessarily  endorsed  by  IDA  or  the  Department  of  Defense.  Likewise,  all  errors  in  the  paper 
are  attributable  only  to  the  authors. 
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EXECUTIVE  SUMMARY 


The  communities  responsible  for  developing,  fielding,  testing  and  operating  the 
Global  Command  and  Control  System  (GCCS)  agree  that  an  evolutionary  acquisition 
approach  is  essential  for  exploiting  fast-moving  commercial  technologies  such  as  those 
underlying  GCCS.  The  creation  of  the  unique  evolutionary  approach  utilized  for  GCCS 
began  when  the  DISA-led  development  team  initiated  work  in  1992.  The  GCCS 
community  subsequently  began  developing  a  more  formal  management  approach  for 
GCCS  in  the  Spring  of  1996.  This  approach  has  been  fleshed  out  and  clarified  in  its 
applications  to  GCCS(Top  Secret)  released  in  the  Summer  of  1997,  and  GCCS(3.0) 
released  in  the  Spring  of  1998. 

This  paper  summarizes  a  “lessons  learned”  study  which  reviewed  DoD’s  approach 
to  managing  the  GCCS  program  on  behalf  of  the  Assistant  Secretary  of  Defense  for 
Command,  Control,  Communications,  and  Intelligence  (ASD/C3I).  This  study,  conducted 
in  the  Fall/Winter  of  1997/98,  provides  a  brief  history  of  the  program,  presents  the  views 
of  the  communities  that  develop,  test,  support,  or  use  GCCS,  and  offers  some  specific 
lessons  learned  for  continuing  to  strengthen  the  management  of  the  program. 

The  GCCS  community  has  made  significant  progress  in  the  last  two  years  toward 
establishing  a  management  approach  for  evolutionary  acquisition  programs.  Indeed,  its 
innovations  in  the  areas  of  requirements  definition  and  modified  development  testing 
provide  useful  models  for  other  programs.  The  community  continues  to  develop  and 
strengthen  the  management  process,  and  important  initiatives  were  begun  during  the 
course  of  this  review.  Not  surprisingly,  however,  there  is  still  a  great  deal  of  work 
remaining  to  be  done.  Lessons  learned  and  remedial  actions  are  summarized  below. 

Strategic  Vision  and  Requirements 

•  A  “ strategic  vision with  a  three-  to  five-year  horizon,  is  needed  for  PPBS,  to 
sell/defend  GCCS,  to  force  long-term  thinking,  and  to  keep  the  community  informed. 
Action:  J3 

•  The  requirements  process  has  not  been  closely  followed  in  the  past,  but  will  work 
through  enforcement  and  institutionalization;  a  way  to  allow  high-priority  requirements  to 
advance  rapidly  should  be  found.  Action:  J3,  RWG.  The  EPIP/RID  are  not  timely; 
recommend  detaching  the  RID  for  early  release  and  also  releasing  the  EPIP  earlier. 
Action:  EPIP-D2,  RID-J3 
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•  DARPA  initiatives  should  be  better  coordinated  with  the  GCCS  community  to  avoid 
unforeseen  costs.  Action:  J3,  RWG 

Programming  and  Budgeting 

•  GCCS  3.0  should  be  declared  the  system  baseline  and  a  series  of  benchmarks  should 
be  developed  to  accurately  capture  performance  and  cost  deltas.  Action:  D2,  J3 

Testing  and  Fielding 

•  Further  testing  and  evaluation  are  necessary  to  verify  the  technical  underpinnings  of 
GCCS;  user  feedback  should  be  increased;  and  procedures  for  evolutionary  acquisition 
further  developed.  Action:  D2,  D6,  OSD/DOT&E 

•  Migration  of  JOPES  to  GCCS  was  unsatisfactory  and  the  projected  gains  in 
performance  have  not  occurred;  JOPES  level  1  GSPRs  should  be  fixed  while  efforts  are 
focused  upon  the  long-term  solution  of  BPR.  Action:  D6,  J3,  J4 

Operations  and  Support 

•  Configuration  management  needs  to  improve  coordination  between  the  field  and 
headquarters  while  defining  parameters  to  allow  “hobby-shopping.”  Action:  D6,  J3 

•  The  PM’s  staff  should  be  augmented  to  alleviate  current  personnel  shortages  and  to 
handle  the  expanded  workload  recommended  by  this  study.  Action:  D2 

•  Training  lags  deployment  considerably  and  current  training  efforts  should  extend 
beyond  the  classroom.  Action:  Services,  DISA 


EVOLUTIONARY  ACQUISITION  OF  THE  GLOBAL  COMMAND 
AND  CONTROL  SYSTEM:  LESSONS  LEARNED 


The  developers  of  the  Global  Command  and  Control  System  have  broken  new 
ground  in  creating  an  evolutionary  approach  for  acquiring  defense  information  systems.  In 
the  fall  of  1997,  EDA  was  tasked  by  OSD/C3I  to  conduct  a  GCCS  Management  Lessons 
Learned  Study  in  order  to  capture  the  initiatives  taken  within  DoD  since  early  1995  to 
strengthen  GCCS  program  management.  The  study  is  intended  to  identify  the  strong 
points  in  DoD’s  approach  as  well  as  to  identify  areas  of  continuing  weakness  in  practices 
and  procedures.  In  summation,  the  study  was  asked  to  address  the  question:  Which  GCCS 
management  practices  and  process  work  well,  which  don ’t,  and  what,  if  anything,  should 
be  changed? 

Several  factors  motivated  this  review,  including  increased  interest  from  non-DoD 
parties,  e  g.,  the  General  Accounting  Office,  as  the  program  grows  in  both  cost  and  scope; 
the  desire  to  document  lessons  learned  as  the  first  generation  of  personnel  involved  with 
the  program  departs;  the  need  to  conduct  the  necessary  periodic  management  review  that 
all  programs  are  subject  to;  and  to  see  if  a  general  model  could  be  distilled  for  use  in  other 
similar  programs.  Initial  results  were  briefed  to  OSD/C31  in  December  1997. 

This  paper  summarizes  the  approach  and  findings  of  the  lessons  learned  review. 
Section  A  describes  the  study  approach,  and  the  fact-finding  the  provides  the  basis  for  the 
findings.  Section  B  provides  a  brief  history  of  the  GCCS  program,  highlighting  the  key 
activities  and  events  relating  to  the  management  of  the  program.  Section  C  describes  the 
perspectives  of  the  main  communities  involved  in  the  development,  fielding,  and 
operations  of  the  system.  Section  D  highlights  several  specific  lessons  learned  from  this 
review.  These  lessons  suggest  an  agenda  to  strengthen  the  management  of  GCCS,  and  to 
develop  a  general  model  for  evolutionary  acquisition  that  can  be  applied  to  other  similar 
programs.  Some  concluding  comments  are  presented  in  Section  E. 

A.  APPROACH 

The  fact-finding  in  this  study  was  primarily  accomplished  through  a  series  of 
interviews  conducted  over  a  four-month  period,  beginning  in  September  1997  and 
continuing  through  January  1998.  A  total  of  55  individuals  were  interviewed  (see  the 
Annex  to  this  document  for  a  complete  listing),  representing  the  CINCS,  the  Component 
Commands,  DISA,  the  Joint  Staff,  OSD,  and  the  Services.  On-site  visits  to  the  Commands 
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were  conducted  at  ACC,  ACOM,  CENTCOM,  and  TRANSCOM.  A  small  number  of 
telephone  interviews  were  also  conducted  to  gain  the  perspectives  of  officials  in  EUCOM, 
FORSCOM,  PACOM,  and  USFK.  The  remainder  of  the  interviews  were  done  in  the 
Washington  D  C.  metropolitan  area. 

Individuals  interviewed  were  selected  for  their  experience,  their  position,  or  at  the 
recommendation  of  other  interviewees.  A  rough  balance  was  sought  in  canvassing  each  of 
the  segments  within  the  GCCS  community,  and  at  each  of  the  Commands  visited.  The 
interviews  typically  comprised  two  interviewers  and  one  interviewee,  although  the  precise 
numbers  varied  in  a  few  cases.  Each  interview  lasted  30-60  minutes,  depending  upon 
scheduling  and  the  amount  of  material  to  cover.  When  visiting  a  site,  as  many  as  five  or  six 
interviews  were  accomplished  in  the  span  of  a  single  day. 

Subject  matter  was  tailored  to  take  advantage  of  the  experience  and  perspective  of 
each  interviewee.  Questions  addressed  management-level  issues,  emphasizing  current  and 
future  concerns,  although  historical  perspectives  were  also  valued.  Sample  questions 
might  include:  How  is  training  done  for  GCCS;  is  it  done  well;  are  some  segments  done 
more  effectively  than  others;  what  are  the  shortfalls;  is  the  training  situation  improving  or 
worsening;  and  what,  if  anything,  should  be  changed. 

In  addition  to  these  interviews,  a  number  of  documents  were  reviewed,  including 
both  the  GCCS(Top  Secret)  and  the  GCCS(3.0)  EPIPs;  several  cables  and  briefings 
describing  a  summer  1997  functional  assessment  of  GCCS  conducted  by  EUCOM;1 
minutes  collected  from  a  number  of  meetings;  Executive  and  Congressional  laws, 
regulations,  and  reports,  e.g.,  the  Clinger-Cohen  Act2  and  a  GAO  report  on  performance 
measures;3  and  assorted  other  documents4,  including  a  training  CD-ROM5  and  briefings 
delivered  by  various  segments  of  the  GCCS  community  at  a  Spring  1997  AFCEA  course 


1  Cable  from  U.S.  European  Command  to  the  Joint  Staff  and  DISA.  Subject:  Global  Command  and 
Control  System  (GCCS)  European  Command  Functional  Assessment.  DTG  031715Z  November  1997. 
classified  SECRET.  See  also  U.S.  European  Command  July  1997  USEUCOM  GCCS  Functional 
Assessment  brief.  IDA  log  number  E  98-000256,  classified  SECRET.  See  also  EUCOM  THEATER 
Global  Command  &  Control  System  (GCCS)  User  Survey  blank  form,  uncontrolled  document,  also 
available  at  IDA. 

'  Also  called  the  Information  Technology  and  Management  Reform  Act  of  1996. 

3  Measuring  Performance  and  Demonstrating  Results  of  Information  Technology  Investments.  General 
Accounting  Office.  GAO/AIMD-97-163,  Exposure  Draft.  September  1997. 

’  Especially  CJCSI  6721.01,  Global  Command  and  Control  Management  Structure ,  18  February  1995. 

5  GTN  EWEB  Tutorials.  USTRANSCOM  J3  -  JOPES  Training  Organization.  CD-ROM  for  Microsoft 
Windows.  July  30,  1997. 
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on  the  topic.  These  data  were  collected  and  evaluated  to  augment  the  opinions  solicited  by 
the  interviewers  and  the  judgment  of  the  interviewers  themselves. 

B.  A  BRIEF  HISTORY  OF  GCCS 

To  provide  a  context  for  the  observations  and  lessons  learned  detailed  in 
subsequent  sections,  this  section  provides  a  brief  overview  of  GCCS.  It  traces  the  birth  of 
GCCS  from  WWMCCS  in  1992,  its  August  1996  fielding,  and  its  subsequent  evolution  up 
to  early  1998.  Emphasis  is  placed  upon  the  role  of  acquisition  reform. 

1.  WWMCCS  and  the  Origins  of  GCCS 

The  Worldwide  Military  Command  and  Control  System  (WWMCCS)  was  a 
mainframe-based,  Honeywell  system  first  designed  in  the  1960’s  to  provide  automation 
support  for  deliberate  planning  and  secure  messaging  among  the  major  warfighting 
Commands.  WWMCCS  ran  in  a  Top  Secret  environment,  so  terminals  were  typically 
located  in  vaults  or  other  highly  secured  installations,  and  were  not  widely  available  to 
staff  in  Command  centers.  WWMCCS  was  maintained  by  dedicated  administrators;  over 
the  years  there  emerged  a  cadre  of  users  supporting  both  deliberate  planning  and  crisis 
action  planning,  as  well  as  deployment  planning. 

As  technology  advanced  and  the  potential  to  exploit  automation  grew,  upgrades  to 
WWMCCS  were  attempted  under  the  WIS  and  WAM  programs.  These  programs  spanned 
from  the  early  1980’s  until  late  1992.  Despite  attempts  to  upgrade  WWMCCS,  its 
capabilities  remained  limited,  and  access  to  the  system  was  restricted  by  its  high  level  of 
classification.  In  addition,  there  were  growing  concerns  that  the  expenses  of  the  various 
upgrades  were  not  justified  by  the  capabilities  gained. 

A  major  review  conducted  in  June  1992  by  a  C4I  Interoperability  Tiger  Team 
found  that  WWMCCS  was  deficient  in  meeting  warfighter  requirements.  Deficiencies 
resulted  from  problems  in  the  user’s  ability  to  enter  and  access  information;  a  lack  of 
software  flexibility  to  modification;  an  unresponsive,  inflexible,  and  expensive  system 
architecture;  a  lack  of  interoperability  with  other  command  and  control  (C2)  systems;  the 
high  cost  of  maintaining  below-Top  Secret  data  (which  constituted  the  bulk  of  WWMCCS 
data)  on  a  Top  Secret  system;  the  inability  of  doctrinal,  operational,  organizational, 
training,  or  material  alternatives  to  remedy  these  deficiencies;  and  the  perception  that 


mainframe  computing  was  outmoded.6  After  years  of  investment  and  user  disappointment, 
WWMCCS  had  effectively  reached  a  dead  end.  A  replacement  system  was  needed. 

In  December  1992,  funding  for  WWMCCS  modernization  and  improvement  was 
terminated;  this  funding  was  redirected  to  develop  and  field  a  WWMCCS  follow-on 
program,  GCCS.  In  contrast  to  WWMCCS,  GCCS  was  to  be  a  commercially  based 
system  in  a  client-server  environment.  It  would  operate  on  the  DoD’s  classified  version  of 
the  Internet  (SIPRNET),  and  therefore  provide  secure  access  to  a  much  wider  range  of 
users.  This  approach  emphasized  linking  C2  systems  together  to  allow  unencumbered  data 
exchange,  immediate  and  nearly  equal  access  to  data  among  a  much  broader  circle  of 
users,  increased  interconnectivity,  low  cost,  a  graphical  user  interface,  frequent  and  rapid 
upgrades,  and  evolution  over  revolution  in  acquisition.  Essentially,  GCCS  was  intended  to 
emulate  trends  already  under  way  in  corporate  America. 

Development  of  GCCS  was  accomplished  through  a  partnership  of  the  Defense 
Information  Systems  Agency  (DISA),  the  Joint  Staff  and  the  Office  of  the  Assistant 
Secretary  of  Defense  for  Command,  Control,  Communications,  and  Intelligence 
(ASD/C3I).  Deemed  an  evolutionary  acquisition  program  in  the  GCCS  migration  strategy, 
the  program  was  not  subject  to  oversight  by  the  Major  Automated  Information  Systems 
Review  Council  (MAISRC)  until  August  1994.  This  decision  was  due  in  part  to  the 
perception  that  MAISRC  acquisition  procedures  were  cumbersome  and  time  consuming, 
and  would  only  serve  as  a  stumbling  block  to  the  flexible  and  rapid  development  of  GCCS. 

2,  The  Evolution  of  GCCS 

In  August  1996,  GCCS(2.1)7  was  fielded  and  declared  the  “System  of  Record” 
(SoR).8  The  majority  of  WWMCCS  was  concurrently  shut  down,  although  a  small  portion 
remained  in  operation  until  GCCS(Top  Secret)  was  declared  SoR  in  July  1997.  It  is 
envisioned  that  eventually  multi-level  security  will  allow  the  two  separate  GCCS  systems 
to  combine  as  one,  but  until  then,  the  much  larger  GCCS  Secret-high  system  will  remain 
discreet  to  facilitate  ease  of  use  and  to  minimize  cost. 


6  For  a  more  lengthy  discussion  of  these  deficiencies  and  a  then  contemporary’  view  of  GCCS.  see 
Validation  Approval  of  Mission  Need  Statement  (K4NS)  for  Global  Command  and  Control  System 
(GCCS).  Joint  Staff.  8  June  1995. 

Earlier  versions.  GCCS(l.O)  and  GCCS(l.l),  were  deemed  not  ready  for  fielding. 

8  System  of  Record  (SoR)  is  a  new  term  designed  to  avoid  the  administrative  entanglements  associated 
with  Initial  Operating  Capability  (IOC). 
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The  fielding  of  GCCS(2.1)  was  a  difficult  process,  hampered  by  insufficient 
developmental  and  operational  testing,  untrained  users,  poor  or  missing  documentation, 
and  a  variety  of  technical  glitches.  Numerous  GSPRs  (GCCS  Software  Problem  Report) 
were  filed.  Some  were  addressed  in  GCCS(2.2.x),  but  many  were  never  fixed  in  the  hope 
that  the  follow-on,  GCCS(3.0),  would  solve  them. 

This  next  main  version  to  be  fielded  was  GCCS(Top  Secret)  in  July  1997. 
GCCS(Top  Secret)  essentially  provided  GCCS(2.1)  capabilities  to  a  much  smaller  group 
of  users  on  a  Top  Secret  network.  It  did  not  present  the  same  degree  of  difficulty  as 
GCCS(2.1),  but  nonetheless  many  problems  remained,  e.g.,  management  of  double 
encryption  over  the  SIPRNET.  GCCS(Top  Secret)  was  the  first  version  of  GCCS  for 
which  the  evolutionary  acquisition  process  was  employed  and  for  which  an  EPIP  was 
developed.9 

The  next  iteration  of  the  GCCS  Secret -high  system  is  GCCS(3.0),  which  is  in  the 
process  of  fielding  as  this  document  is  being  written  (winter  1998).  The  fielding  process 
has  changed  significantly  as  the  result  of  the  GCCS(2.1)  experience.  Specifically,  more 
thorough  testing  was  done,  including  Modified  Development  Testing  (MDT),  which 
brought  the  testers  out  into  the  field  to  address  site  unique  conditions,  while  the  users  saw 
this  as  an  opportunity  to  learn  and  express  their  needs  directly  to  the  developer. 
Documentation  has  improved  and  training  is  less  a  problem  as  users  now  have  1 8  months 
experience  using  GCCS.  Nonetheless,  it  remains  to  be  seen  how  successful  fielding  will 
be.  An  EPIP  was  written  for  GCCS(3.0).10 

Capabilities  and  features  of  GCCS(3.0)  include  the  Common  Operational  Picture 
(COP),  the  Joint  Operations  Planning  and  Execution  System  (JOPES),  the  air-tasking 
order,  weather  data,  intelligence  imagery,  ballistic  missile  defense,  web  pages,  chat  groups, 
e-mail,  and  many  other  salient  applications.  All  GCCS(3.0)  applications  are  designed  to 
comply  with  the  standards  set  by  the  DIICOE  (Defense  Information  Infrastructure 
Common  Operating  Environment).  This  represents  a  major  difference  between  GCCS(2.x) 
and  GCCS(3.0),  as  it  will  allow  many  more  applications  to  be  efficiently  linked,  whereas 
GCCS(2.1)  was  essentially  a  migration  from  the  mainframe  environment  to  the  client- 

9  Globa!  Command  and  Control  System  -  “Top  Secret"  GCCSfT),  Evolutionary  Phase  Implementation 
Plan,  Phase  1.  no  author  listed,  December  1996.  Note:  this  document  is  often  attached  under  the  cover 
of  the  Requirements  Implementation  Document ,  citation  otherwise  the  same  except  for  the  Joint  Staff  as 
author. 

10  Global  Command  and  Control  System  (GCCS)  Requirements  Implementation  Document  (RID)  and 
Evolutionary  Phased  Implementation  Plan  (EPIP)  Phase  II,  GCCS  Version  3.0 ,  Defense  Information 
Systems  Agency,  Joint  Interoperability  and  Engineering  Organization,  24  October  1997. 
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server  environment.  In  addition,  it  allows  operating  system  and  database  management 
system  upgrade  to  more  current  and  widely  supported  software. 

3.  The  GCCS  Development  Strategy 

Another  perspective  that  helps  in  understanding  what  was  attempted  with  GCCS, 
and  to  evaluate  what  was  accomplished,  is  to  view  its  history  in  terms  of  the  developers’ 
underlying  strategy.  This  strategy  focused  on  three  main  objectives.  The  first  was  to 
establish  the  backbone  of  a  client-server  information  system  using  the  SIPRNET  to  link 
key  C2  centers.  The  second  was  to  establish  and  maintain  seamless  interoperability  and 
supportability  of  C2  functions  among  these  centers,  so  that  important  planning  and 
operational  functions  and  data  could  be  used  commonly  across  the  network.  The  third  was 
to  establish  an  evolutionary  acquisition  approach  that  would  develop,  test,  and  field 
manageable  increments  of  GCCS.  This  approach  would  allow  DoD  to  expand  C2 
capabilities  by  incrementally  expanding  the  scope,  functional  utility,  and  speed  of 
command  and  control  functions.  Although  significant  challenges  remain,  this  three-part 
strategy  has  proven  to  be  largely  successful. 

a.  SIPRNET  backbone 

GCCS  clearly  has  succeeded  in  meeting  its  first  goal  of  exploiting  SIPRNET  to 
establish  connectivity  among  headquarters  and  Commands.  D1SA  accomplished  this,  in 
part,  by  taking  the  lead  in  buying  the  equipment  needed  to  establish  the  backbone  of  the 
system  at  39  key  headquarters  and  field  Commands  and  15  database  sites.  This  helped 
ensure  that  the  key  headquarters  and  Commands  became  users  of  the  system.  Following 
this  lead,  connectivity  has  been  established  at  hundreds  of  additional  sites.  SIPRNET 
connectivity  supports  web  technology  such  as  e-mail,  web  pages,  newsgroups,  and  chat 
rooms,  and  has  provided  significant  advances  in  the  capability  of  Commands  and 
headquarters  to  exchange  information. 

The  contribution  of  these  SIPRNET  connectivity  functions  to  C2  deserves 
emphasis.  Although  GCCS  expanded  the  availability  and  scope  of  C2  capabilities  well 
beyond  those  available  with  WWMCCS,  there  still  was  a  tendency  in  the  early  stages  of 
fielding  GCCS  to  judge  it  primarily  in  comparison  with  the  JOPES  functions  that  had  been 
provided  by  WWMCCS.  This  perspective  was  the  result  of  a  user  community  that  stressed 
the  transition  of  WWMCCS  functions  over  the  addition  of  new  functionality.  The  resulting 
bias,  combined  with  the  lack  of  a  user-validated  requirements  document,  led  the  OT&E 
community  to  test  primarily  for  WWMCCS  functionality,  e.g.,  JOPES,  GSORTS,  JMAS, 
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etc.,  in  GCCS.  Since  it  is  unrealistic  to  expect  a  new  system  to  uniformly  outperform  a 
mature  system  of  25  years,  JOPES  shortfalls  by  WWMCCS  standards  were  reported. 

Consequently,  the  persistent  problems  with  JOPES  automation,  particularly  in 
supporting  crisis  action  planning  (which  in  some  cases  were  aggravated  by  the  transition 
to  GCCS)  became  the  focal  point  for  judging  GCCS.  This  perspective  created  an  unfair 
portrait  of  GCCS,  because  the  complaints  about  JOPES  overshadowed  the  other 
contributions  of  GCCS  through  increased  connectivity  and  situational  awareness.  The 
community  now  takes  a  more  balanced  view  of  GCCS.  Indeed,  even  JOPES  users  that 
remain  disappointed  with  JOPES  performance  agree  that  GCCS  has  improved  C2. 

b.  interoperability  and  supportability 

The  second  broad  goal  of  the  GCCS  acquisition  strategy  is  to  achieve  global 
interoperability  of  C2  functions  across  headquarters  and  field  Commands.  The  WWMCCS 
centralized  mainframe  computing  environment  ensured  interoperability  for  the  limited 
functions  it  supported,  since  the  mainframe  environment  naturally  imposed 
standardization.  In  non-WWMCCS  C2  functional  areas,  however,  the  field  Commands 
and  Services  built  unique  architectures,  which  provided  little  or  no  interoperability. 

Accomplishing  and  maintaining  interoperability  across  the  Commands  and  Services 
will  require  balancing  the  field  commanders’  prerogatives  to  modify  or  build  new  C2 
applications  against  the  benefits  of  a  common  framework  that  provides  interoperability. 
GCCS  developers  have  adopted  a  two-pronged  approach  to  achieve  this. 

The  first  is  to  promote  standardization  within  GCCS.  The  developers  have 
established  standards  for  hardware  and  software  that  are  intended  to  guarantee 
interoperability.  The  centerpiece  is  the  adoption  of  the  Defense  Information  Infrastructure 
Common  Operating  Environment  (DII-COE).  The  theory  is  that  using  standard  hardware 
and  software,  along  with  common  databases,  will  facilitate  interoperability  within  the 
GCCS  user  community. 

The  second  prong  of  the  approach  was  not  just  to  standardize  within  GCCS,  but  to 
actually  make  GCCS  the  “standard.”  Much  as  Microsoft  Windows  is  the  standard 
operating  system  for  desktop  computing,  DISA  sought  to  make  GCCS  the  standard  C2 
system  for  the  purpose  of  further  easing  interoperability  and  supportability.  In  addition  to 
funding  the  fielding  of  a  system  backbone,  this  was  accomplished  by  incorporating 
functions  in  high  demand  by  users  into  the  COE,  which  resulted  in  increasing  GCCS’ 
“market  share”  of  C2  systems. 
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c.  evolutionary  acquisition 


The  third  major  objective  of  the  GCCS  strategy  was  to  establish  an  evolutionary 
approach  for  expanding  GCCS  functions.  Initially  this  was  devoid  of  many  of  the 
traditional  aspects  of  an  acquisition  program,  e.g.,  documentation,  management  structure, 
etc.  And  in  many  respects,  the  early  days  of  the  GCCS  development  activity  could  be 
described  as  a  “skunkworks”  operation.  While  GCCS  developers  maintained  close  contact 
with  the  most  senior  leaders  in  ASD(C3I),  DISA,  and  the  Joint  Staff,  they  did  not  interact 
extensively  with  the  communities  responsible  for  programming  and  budgeting,  testing, 
fielding,  or  operations  and  support.  This  approach  enabled  the  developers  to  focus  on  the 
technological  tasks  at  hand,  and  it  possibly  contributed  to  the  speed,  and  perhaps  the 
viability,  of  the  development.11  The  downside  of  this  approach,  however,  is  that — in 
retrospect,  at  least — many  challenges  involved  in  fielding  the  system  were  not  anticipated 
and  thus  were  not  prepared  for.  Poor  preparation  by  the  development  community  (e  g., 
DISA)  led  to  difficulties  testing  and  fielding,  and  many  Commands  were  forced  into 
months  of  catch-up  in  establishing  capable,  trained  operators  and  system  administrators. 

In  reaction  to  this  atypical  pattern  of  developing  and  acquiring  a  major  computer 
system,  the  Office  of  the  Inspector  General  (IG)  audited  the  management  of  GCCS  and 
issued  a  report  in  May  1995  critical  of  several  aspects  of  the  program.12  The  IG 
recommended  that  GCCS  be  designated  a  formal  acquisition  program  with  centralized 
management  and  be  subject  to  the  MAISRC  process,  that  the  system  be  baselined,  and 
that  a  number  of  acquisition  and  management  documents  be  written,  including  a  Mission 
Needs  Statement,  an  Operational  Requirements  Document,  an  Acquisition  Strategy  and 
Plan,  a  Test  and  Evaluation  Master  Plan,  and  an  Integrated  Logistical  Support  Plan 
(ILSP).  The  audit  also  noted  that  testing  was  inadequate.  DISA,  the  Joint  Staff,  and  OSD 
concurred  with  all  twelve  suggestions. 

Following  the  IG  report,  OSD  undertook  to  develop  a  more  formal  acquisition 
strategy  for  GCCS  while  preserving  the  principles  of  streamlined,  evolutionary  acquisition. 
In  order  to  help  develop  this  new  acquisition  strategy,  an  informal  Working  Group  on 
Evolutionary  Acquisition  was  established  in  March  of  1996.  This  group  included  the  key 
working-level  players  in  the  GCCS  community  from  DISA,  the  Joint  Staff,  the  Services, 

1 1  The  factors  which  led  to  GCCS  development  are  threefold:  technology  which  allowed  for  a  successful 
client-server  environment:  declining  budgets  which  forced  cooperation  and  a  turning  away  from 
expensive  stovepipe  systems;  and  the  force  of  personality  embodied  by  RADM  John  Gauss  who  led  the 
development  of  the  GCCS. 

u  Department  of  Defense.  Office  of  the  Inspector  General,  Audit  Report  on  Management  of  the  Global 
Command  and  Control  System.  Report  No.  95-201.  May  24.  1995. 
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and  OSD.  After  extensive  deliberations,  in  the  Summer  of  1996  the  group  agreed  upon  an 
evolutionary  acquisition  approach.13  This  approach  meets  the  concerns  of  the  IG  Report, 
while  retaining  the  flexibility  needed  to  rapidly  field  new  capabilities.  Although  too  late  to 
have  significant  impact  upon  the  August  1996  fielding  of  GCCS(2.1),  the  process  was 
partially  applied  to  the  next  iteration  of  GCCS,  the  GCCS(Top  Secret)  system  fielded  in 
the  summer  of  1997.  The  new  approach  is  also  being  used  in  the  fielding  of  GCCS(3.0), 
which  is  expected  to  be  fielded  in  the  Spring  of  1998. 

A  major  element  of  this  new  acquisition  strategy  is  the  Evolutionary  Phase 
Implementation  Plan  (EPIP).  The  EPIP  is  essentially  a  contract  among  the  major 
components  of  the  GCCS  community.  It  contains  a  Requirements  Implementation 
Document  (RID),  a  functional  description,  information  on  the  system  architecture, 
concepts  of  operation  for  security,  testing,  training,  and  production  operations,  as  well  as 
an  ILSP,  costing  data,  and  a  risk  assessment  chapter.  The  EPIP  is  authored  by  DISA  with 
Joint  Staff  assistance.  The  document  is  jointly  coordinated  by  the  Commands  and 
MAISRC  principals  and  approved  by  the  ASD/C3I,  the  J3,  and  DISA.  The  EPIP  contains 
much  of  the  same  information  required  under  the  MAISRC  process  of  project 
documentation,  but  is  significantly  more  integrated,  timely,  and  streamlined.  The  EPIP  is 
an  unclassified  document  distributed  widely  among  the  Department,  to  include  the 
Commands  and  Services. 

A  second  significant  outcome  of  the  new  acquisition  strategy  was  the  formulation 
of  a  requirements  process.  Up  to  that  point,  the  requirements  process  had  been  ad  hoc  and 
subjective  rather  than  a  formal  assessment  of  cost,  risk,  and  prioritization.  The  new 
requirements  process  was,  in  its  essence,  a  fairly  typical  one.  It  required  that  the 
customer’s  demands  (i.e.,  CINCS)  be  weighed  in  terms  of  cost,  risk,  and  priority  by  a 
requirements  working  group  and  in  several  assess  phases  led  by  the  Joint  Staff  and  DISA. 
Despite  being  formulated  in  1996,  the  requirements  process  was  applied  to  neither 
GCCS(Top  Secret)  nor  GCCS(3.0).  It  is  expected  that  all  further  iterations  of  GCCS  will 
be  subject  to  the  requirements  process. 

A  key  product  of  the  requirements  process  is  the  Requirements  Identification 
Document  (RID),  which  describes  the  functions  that  will  be  added  in  an  upcoming 
development  phase.  The  RID  is  intended  to  provide  an  early  overview  of  the  development 


13  A  description  of  this  approach  may  be  found  in  An  Evolutionary  Acquisition  Strategy  for  the  Global 
Command  and  Control  System  (GCCS).  Richard  H.  White.  David  R.  Graham,  and  Johnathan  A.  Wallis, 
Institute  for  Defense  Analyses,  IDA  Paper  P-3315.  September  1997. 
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activities  to  be  pursued  in  an  implementation  phase,  and  gives  advance  notice  to  testers 
and  field  personnel  of  the  GCCS  functions  that  will  be  added  in  the  coming  months. 

C.  COMMUNITY  VIEWS 

The  GCCS  community  is,  in  fact,  a  collection  of  different  communities,  each  with 
its  own  view  and  understanding  of  GCCS.  This  collective  may  be  roughly  divided  into  six 
sub-communities:  testing  and  evaluation;  development;  the  Commands;  the  Joint  Staff; 
budgeting;  and  oversight.  The  following  descriptions  of  each  community’s  views  are 
fundamentally  composite  sketches  which  portray  their  general  outlook  and  concerns. 
Specific  management  issues  will  be  addressed  later  in  the  paper. 

1.  Testing  and  evaluation 

The  GCCS  community  was  initially  distraught  over  the  fielding  of  GCCS, 
especially  versions  prior  to  and  including  GCCS(2.1).  Many  outside  the  development 
community,  particularly  operational  testers,  were  frustrated  by  the  resistance  of  developers 
to  thoroughly  test  GCCS.  And  the  Testing  and  Evaluation  (T&E)  community  itself  was 
unsure  what  to  test,  given  the  amorphous  nature  of  the  system  and  unclear  user 
requirements,  resulting  in  too  much  emphasis  upon  JOPES  at  the  expense  of  other 
applications.  The  T&E  community  perceived  that  its  role  as  the  technical  guarantor  of  the 
system  was  greatly  undermined  in  the  rush  to  field  these  versions.14  The  IG  report,  for 
example,  noted  that  GCCS  versions  1.0  and  1.1  had  not  been  subjected  to  adequate 
developmental  or  formal  operational  testing  and  evaluation  prior  to  fielding.  Likewise, 
GCCS(2.1)  had  not  been  not  adequately  tested  at  the  developmental  stage.  This  resulted 
in  a  “disastrous”  fielding  experience,  which  created  hard  feelings  that  still  persist  today  in 
various  segments  of  the  community. 

The  GCCS  community  has  worked  hard  to  improve  T&E.  One  important 
innovation  is  Modified  Development  Testing  (MDT).  MDT  provides  a  phased  approach  to 
developmental  testing  and  focuses  on  early  field  feedback  rather  than  simply  delivering  the 
“next  great  thing”  to  an  unsuspecting  user.  (For  example,  in  late  1997  the  final  phase  of 
MDT  testing  for  GCCS(3.0)  took  the  release  out  of  the  lab  for  early  testing  at  a  number  of 
sites.)  In  parallel,  a  recognition  is  developing  within  among  the  T&E  community  that  it 
must  continue  to  adapt  to  the  nature  of  evolutionary  acquisition,  for  example,  by  testing 
only  the  deltas  of  the  latest  software  release,  as  opposed  to  testing  the  entire  system  with 

14  It  should  be  noted  that  testing  now  supports  a  decision  by  the  user  to  field,  and  not  the  acquisition 
community. 
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each  new  release.  In  addition,  the  overall  community  is  motivated  to  not  repeat  the  early 
difficulties  in  fielding  GCCS  and  is  increasingly  cognizant  of  T&E  as  an  enabler,  and  not  a 
roadblock  to  development.  Finally,  testing  now  supports  a  user  decision  to  field  and  not  an 
acquisition  decision. 

Key  operational  tests,  such  as  the  robustness  of  the  system  under  wartime  stresses, 
remain  to  be  conducted.  Entry  and  exit  criteria  are  still  felt  to  be  absent,  or  ignored.15  And 
questions  concerning  the  long-term  nature  of  the  system  must  be  answered.  For  example, 
some  underlying  issues  in  the  shift  from  a  mainframe  to  a  client-server  architecture  have 
not  yet  been  validated  by  the  T&E  community. 

2.  Development 

The  development  community  was  a  driving  force  behind  the  conception, 
development,  and  early  fielding  of  GCCS.  Not  surprisingly,  this  community  is  inclined  to 
view  GCCS  in  technical  terms.  It  is  proud  of  the  rapid  development  processes  achieved  in 
the  fielding  of  GCCS.  From  the  first  concept  of  GCCS  in  1992,  the  community  developed 
and  fielded  GCCS  as  the  system  of  record  in  under  four  years,  with  more  than  500  user 
sites.  Many  of  the  highly  valued  network  service  features  described  earlier  have  been 
available  since  early  1995.  Developers  believe  they  have  succeeded  in  establishing  the 
basic  foundation  of  platforms,  network  interfaces,  databases,  and  applications  needed  to 
revolutionize  command  and  control. 

3.  Commands 

The  Commands  are  generally  supportive  of  GCCS  and  are  especially  happy  with 
the  increased  interconnectivity  among  users  via  web  pages,  chat  groups,  email,  etc.  Usage 
of  the  Common  Operational  Picture  (COP)  varies,  but  heavy  users,  such  as  CENTCOM 
and  USFK,  are  strong  backers  of  this  application.  The  Joint  Operation  Planning  and 
Execution  System  (JOPES)  performs  satisfactorily  at  some  Commands,  but  heavy  users, 
such  as  ACOM,  FORSCOM,  and  TRANSCOM,  are  dissatisfied  with  the  speed  and 
database  synchronization  of  the  system.  Major  concerns  expressed  by  the  Commands 
include  a  still  lagging  training  program,  high  staff  turnover,  the  limited  deployability  of 
GCCS  to  a  JTF,  and  the  user’s  influence  on  development  priorities.  The  Commands  were 
displeased  with  the  fielding  experience  of  GCCS(2.1)  and  have  welcomed  subsequent 
steps  to  correct  for  this  with  GCCS(3.0).  They  are  quite  pleased  with  MDT,  better 

1  The  February  1998  decision  to  postpone  SoR  on  GCCS(3.0).  due  in  part  to  security  concerns,  represents 
a  positive  step  by  the  users  in  reaffirming  the  role  of  entry/exit  criteria. 
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software  documentation,  and  the  increased  responsiveness  of  GCCS  developers  to  their 
needs. 

4.  Joint  Staff 

The  Joint  Staff  is  a  strong  proponent  for  GCCS.  Despite  the  difficulties  in  fielding 
GCCS,  the  Joint  Staff  believes  GCCS  has  significantly  improved  command  and  control.  It 
believes  that  the  program  has  worked  relatively  well,  and  that  critics  are  often  unduly 
faultfinding.  The  Joint  Staff  is  nevertheless  committed  to  continually  improving  the 
management  of  the  program.  It  collectively  feels  that  many  improvements  have  not  been 
properly  credited  by  critics,  possibly  as  a  result  of  the  informal  processes  by  which  they 
were  made. 

The  Joint  Staff  has  made  significant  strides  in  implementing  a  systematic 
requirements  documentation  and  validation  process.  In  1996,  it  initiated  the  development 
of  the  GCCS  Requirements  Identification  Database  (GRiD),  and  performed  a  systematic 
survey  of  the  Commands  to  identity  their  priority  requirements.  GRiD  thus  provides  a 
repository  of  the  CINCs’  desired  future  capabilities,  and  a  starting  point  for  developing  a 
GCCS  roadmap.  In  the  Fall  of  1997,  the  Joint  Staff  initiated  the  first  set  of  assessments  of 
pending  requirements  to  provide  a  basis  for  the  Review  Board  and  Advisory  Board  to 
recommend  priorities  for  development  activities  beyond  GCCS(3.0). 

Several  other  Joint  Staff  initiatives  are  under  way  to  further  strengthen 
management  of  the  program.  These  include  developing  performance  metrics-both  system 
and  functional-to  aid  in  development  of  a  baseline;  addressing  training  issues;  and 
developing  a  roadmap  for  GCCS. 

5.  Budgeting 

The  budgeting  community  naturally  focuses  on  costs,  and  has  repeatedly  expressed 
concern  about  the  apparent  inability  to  predict  the  budget  requirements  for  GCCS.  The 
budget  community  must  contend  with  the  Department’s  financial  management 
system-PPBS  (Planning,  Programming,  and  Budgeting  System)-which  traditionally  has 
required  detailed  five  or  six  year  program  projections  for  funding,  activities,  and  products. 
Thus  the  budget  community  is  caught  between  the  needs  of  the  PPBS  process  and  the 
desire  to  maintain  flexibility  in  managing  the  GCCS  development  activities.  Budgeteers 
have  had  difficulty  developing  cost  figures  for  several  reasons,  including  the  rapidly 
changing  nature  of  the  program;  the  lack  of  a  clear  vision;  blurred  boundaries  as 


Information  Technology  (IT)  programs  and  infrastructure  merge;  and  the  lack  of  a 
program  baseline  in  GCCS. 

They  also  have  legitimate  concerns  over  Operation  and  Maintenance  (O&M)  costs. 
These  are  ill-defined,  and  believed  to  be  huge,  hidden,  and  growing,  e.g.,  support,  training. 
Some  in  the  budget  community  believe  that  these  hidden  costs  represent  a  potential 
landmine  for  the  program.  Solutions  to  these  problems  have  been  offered,  but  most  go 
significantly  beyond  GCCS,  since  the  problems  stem  from  the  manner  in  which  DoD 
manages  IT  department- wide,  rather  than  having  their  specific  roots  in  GCCS. 

6.  Oversight 

The  oversight  community  (OSD/C3I)  is  generally  pleased  with  the  progress  made 
since  early  1996  in  managing  GCCS.  They  observe  a  great  deal  more  communication 
within  the  GCCS  community.  The  oversight  community  attributes  this  in  part  to  the 
requirement  to  develop  an  EPIP  for  each  major  new  release.  The  process  for  preparing 
each  EPIP  has  forced  the  community  to  address  many  issues,  and  therefore  reduces 
surprises  and  over-inflated  expectations.  The  oversight  community  also  believes  that  the 
new  testing  practices  represent  a  significant  improvement.  The  community  nonetheless 
professes  many  of  the  same  concerns  as  the  budget  community,  particularly  the  potential 
hidden  costs  of  the  system.  It  also  must  concern  itself  with  maintaining  sound  relations 
with  Congress  and  its  watchdog,  the  General  Accounting  Office.  Specific  worries  include 
the  continued  need  to  establish  a  program  baseline  as  required  by  the  Clinger-Cohen  Act, 
and  difficulty  in  costing  the  program,  another  area  of  keen  Congressional  interest. 

D.  LESSONS  LEARNED 

The  lessons  learned  from  the  community’s  past  experiences  with  GCCS  and 
evolutionary  acquisition  suggest  a  number  of  ways  to  improve  future  management  of  the 
program.  Not  all  of  these  lessons  learned  result  in  policy  prescriptions,  since  some  are 
already  being  addressed  or  may  be  characterized  more  as  observations.  Other  lessons 
learned,  however,  provide  insight  into  not  only  GCCS  but  also  for  all  programs  utilizing 
evolutionary  acquisition.  The  section  is  divided  into  four  parts  (Figure  1),  which  loosely 
trace  the  process  from  idea  generation,  through  the  PPB  process,  testing  and  fielding,  and 
finally  to  the  operations  necessary  to  support  the  fielded  system. 


Figure  1.  GCCS  Lessons  Learned  Organization 


1.  Strategic  Vision  and  Requirements 

Lesson  1:  The  GCCS  community  needs  a  strategic  planning  process  that  would  develop 
a  three-  to  five-year  roadmap  showing  how  GCCS  links  to  JV20J0. 

One  common  desire  expressed  by  the  GCCS  community  is  the  need  for  a  strategic 
vision,  or  a  roadmap,  to  connect  implementation  documents  such  as  the  EPIP  to  vision 
statements  such  as  Joint  Vision  2010.  The  reasons  behind  this  are  manifold,  including  the 
need  to  link  upgrades  of  equipment,  license  purchases,  and  training  to  some  overall  plan. 
Similarly,  officials  responsible  for  programming  and  budgeting  could  better  anticipate 
programmatic  needs  if  a  general  roadmap  were  available.  In  addition,  some  of  the 
community’s  coordination  problems  with  DARPA  (see  Lesson  7)  could  be  eased  by 
including  a  section  discussing  projected  technologies  and  applications  that  might  affect 
GCCS.  Finally,  a  roadmap  would  aid  in  keeping  the  community  informed,  would  develop 
a  common  vision  of  the  future,  and  would  aid  in  selling/defending  the  program  to  those 
outside  the  community. 

The  roadmap  would  include  a  three-  to  five-year  projection  of  GCCS  functions, 
concepts  of  operations,  performance,  users,  and  architectures.  It  would  be  a  brief  annual 
document  intended  to  inform  the  community  of  the  leadership’s  intentions.  This  process  is 
essential  for  setting  the  future  course  for  GCCS,  and  for  building  the  bridge  that  ensures 
GCCS  mid-term  development  activities  support  the  long-range  objectives  suggested  in 
JV2010.  It  differs  from  an  Operational  Requirements  Document  (ORD)  in  that  it  is  not  a 
binding  document  containing  contractual  performance  goals,  but  a  more  informal,  and 
hence  flexible,  document  that  provides  guidance  without  becoming  a  dated  straitjacket. 


The  roadmap  should  be  relatively  general,  while  addressing  the  full  range  of  system 
development,  testing,  fielding,  and  operations  and  support  issues.  Topics  to  be  addressed 
would  likely  include,  but  not  be  limited  to: 


future  capabilities 
depth  of  fielding 
system  architecture 
interoperability 
refresh  cycles 
future  of  DIICOE 


•  security 

•  operations  and  support 

•  related  development  activities 

•  C2  vs.  fire  control  functions 

•  concepts  of  operations 

•  future  of  SIPRNET/DISN 


The  roadmap  would  provide  a  strategic  front-end  for  the  Joint  Staff  s  requirements 
process,  and  thus  should  be  prepared  for  the  GCC  Review  Board,  chaired  by  the  Vice- 
Director  J6. 

Lesson  2:  The  requirements  process  needs  to  he  strengthened  and  enforced.  The  EP1P 
and  the  RID  need  to  he  made  more  timely. 

The  GCCS  requirements  process  was  outlined  relatively  late  in  the  program  (early 
1996)  in  response  to  planning  uncertainties  inherent  in  the  absence  of  a  requirements 
process.  One  difficulty  that  has  subsequently  arisen  is  between  a  CENC’s  “fast-track” 
requirements  and  the  legal  inability  of  the  Joint  Staff  to  force  the  CINC  to  comply  with  the 
vetting  necessary  in  the  more  lengthy  and  formalized  requirements  process. 

One  key  aspect  of  the  GCCS  requirements  process  is  that  it  has  been  very 
responsive  to  CINC  demands.  Those  CINCs  who  have  chosen  to  weigh  in  typically  have 
gotten  their  high-priority  applications  fielded  through  what  has  been  called  a  “fast-track” 
fielding  process.  Typically,  these  CINC  requirements  stem  from  experimental  applications, 
such  as  developed  under  DARPA  ACTD  programs  for  a  CINC,  e.g.,  DART,  or  from  pre¬ 
existing  commercial  (COTS)  or  government  (GOTS)  applications.  The  responsiveness  of 
the  process  to  the  CINC’s  requirement  is  a  clear  advantage  to  the  user. 

Unfortunately,  this  “fast-track”  approach  also  has  had  a  cost.  Until  recently,  the 
process  typically  had  not  provided  for  the  systematic  review  of  requirements.  Great 
emphasis  was  placed  on  fielding  the  new  applications  desired  by  the  CINCs,  and,  in  the 
view  of  many,  too  little  emphasis  had  been  given  to  the  requirement  to  improve  the  quality 


of  existing  applications.  Testers,  Service  programming  and  budgeting  officials,  and  many 
in  the  field  Commands  expressed  concern  that  this  approach  led  to  an  imbalance  in  the 
fielding  of  new  applications  versus  improving  existing  applications.  This  approach  also 
surprises  personnel  responsible  for  funding,  training,  and  support  of  these  applications, 
and  undermines  the  orderly  testing  of  new  applications. 

The  Joint  Staff  has  begun  addressing  this  issue  through  its  existing  requirements 
process.  For  example,  in  establishing  requirements  for  Phase  II  of  GCCS(3.0),  the  Joint 
Staff  approved  some  “fast-track”  fielding  proposals  but  also  decided,  for  the  first  time,  to 
delay  the  fielding  of  other  proposed  “fast-track”  requirements.  As  the  Joint  Staff  continues 
to  develop  the  GRiD  and  assessment  process,  and  to  enforce  its  requirements  process,  it 
should  increasingly  be  able  to  assess  and  decide  on  such  “fast-track”  proposals. 

The  Joint  Staffs  ability  to  handle  “fast-track”  requirements  will  be  significantly 
strengthened  by  establishing  a  GCCS  programmatic  roadmap  along  the  lines  outlined  in 
the  preceding  section.  The  roadmap  should  reduce  surprises,  because  it  will  provide  a 
survey  of  ACTDs  and  other  experiments  or  development  activities  that  could  generate 
requirements.  These  then  could  be  folded  into  the  Joint  Staffs  requirements  assessment 
process,  along  with  requirements  entering  through  the  formal  requirements  process.  In 
combination,  the  roadmap  and  strengthened  Joint  Staff  requirements  process  provide  the 
mechanisms  needed  to  address  the  problems  that  have  been  raised  in  the  past  with  decision 
making  associated  with  “fast-track”  fielding.  Clearly,  this  system  can  and  should 
accommodate  “fast  tracking,”  but  it  should  be  done  using  a  structured  decision-making 
process  that  weighs  the  costs  and  benefits  of  each  idea. 

A  second  part  to  this  lesson  concerns  the  Evolutionary  Phase  Implementation  Plan. 
The  EPIP  provides  a  contract  among  the  developers,  overseers,  testers,  and  users, 
defining  the  goals  and  plans  for  each  phase  of  acquisition.  It  initially  was  intended  that  the 
EPIP  would  be  published  at  the  outset  of  each  phase  and  used  as  a  decision-making 
document.  Instead,  the  EPIP  has  been  issued  near  the  end  of  the  development  phase, 
shortly  before  the  onset  of  testing  and  fielding.  The  EPIP  is  best  described  as  a 
compilation  of  decisions  that  have  already  been  made,  as  opposed  to  a  decision  document 
itself. 

Nevertheless,  many  interviewees  have  observed  that  the  process  for  developing  the 
EPIP  has  proven  to  be  more  valuable  than  the  document  itself,  because  it  has  promoted 
communication  across  the  involved  communities,  and  has  contributed  to  the  resolution  of 
numerous  issues.  Beyond  this,  it  serves  as  a  significant  and  valuable  source  of  information. 


especially  for  the  field  Commands  absent  from  the  day-to-day  decision-making  in 
Washington. 

The  EPIP  itself  provides  a  good  description  of  program  changes,  and  it  generally 
answers  the  key  questions  concerning  what  is  to  be  done,  when  is  it  to  be  done,  who  is 
responsible,  and  what  resources  are  needed.  The  document  does  have  flaws,  however. 
Gaps  in  coverage  include  incomplete  assignment  of  responsibilities;  insufficient  coverage 
of  O&S  costs;  too  many  placeholders,  e.g.,  the  TEMP;  and  a  number  of  other  issues  that 
require  attention,  although  a  roadmap  (see  Lesson  1)  would  address  a  large  number  of 
these.  Future  versions  of  the  EPIP  should  be  simplified  by  reducing  the  amount  of 
extraneous  data  present. 

The  Requirements  Implementation  Document  draws  on  requirements  from  the 
GRiD  database  that  form  the  basis  for  the  EPIP.  Since  requirements  are  known 
substantially  in  advance  of  the  many  other  types  of  information  contained  in  the  EPIP, 
these  should  be  detached  and  published  as  early  as  possible  to  allow  the  community  to 
react.  Secondly,  the  EPIP  should  be  pushed  up  in  advance.  Although  it  is  unlikely  that  it 
will  ever  be  used  as  a  decision-making  document  (this  will  happen  instead  in  the  Assess 
phase  of  the  requirements  process),  it  will  allow  the  community  to  better  prepare  for  the 
next  release  of  GCCS;  e.g.,  the  training  program  could  be  developed  before  the  version  is 
released. 

Lesson  3:  DART  A  needs  to  be  better  coordinated  with  the  GCCS  community. 

One  repeated  concern  expressed  by  the  GCCS  community,  and  the  Services  in 
particular,  has  been  the  lack  of  coordination  between  the  community  and  the  Defense 
Advanced  Research  Projects  Agency  (DARPA).16  DARPA  initiatives,  while  useful  and 
innovative,  often  arrive  with  little  forewarning.  As  a  result,  when  DARPA-authored 
software  is  added  to  the  GCCS  build  at  the  request  of  a  sponsoring  CINC,  the  Services, 
who  fund  most  of  GCCS,  are  often  caught  short  financially.  In  addition,  DARPA  does  not 
consider  the  support  required  by  the  software,  e.g.,  training,  which  represents  a  further 
burden  for  the  Services  beyond  paying  for  the  software. 

Two  potential  solutions  exist  to  strengthen  coordination  between  the  GCCS 
community  and  DARPA.  The  first  is  to  have  DARPA  brief,  on  a  quarterly  basis,  the 

DARPA  is  chartered  as  a  research  agency  and  should  not  be  building  software  applications  for  the  field. 
Regardless  of  this  apparent  breach  of  the  charter,  it  would  be  foolish  for  the  GCCS  community  to 
discard  DARPA’s  valuable  contributions  to  GCCS  based  on  a  theoretical  notion  of  how  the  Agency 
should  operate. 


17 


GCCS  Requirements  Working  Group.  The  second  solution  is  to  incorporate  a  section  into 
the  Strategic  Vision  (see  Lesson  1)  that  covers  a  number  of  future  technologies  or  studies 
that  may  affect  GCCS.  In  addition,  the  Strategic  Vision  may  aid  DARPA  in  understanding 
what  types  of  technology  would  be  most  useful  to  the  GCCS  community,  and  thus  allow 
them  to  channel  their  efforts  versus  the  current  undirected  studies. 

2.  Programming  and  Budgeting 

Lesson  4:  GCCS(3. 0)  needs  to  be  baselined  in  order  to  develop  system,  functional,  cost, 
and  measurement. 

GCCS  does  not  have  a  baseline.  A  baseline  provides  a  snapshot  of  a  program  in 
terms  of  performance  and  cost,  and  allows  any  changes  against  this  baseline  to  be 
measured.  A  baseline  is  needed  for  several  reasons,  including  compliance  with  the  Clinger- 
Cohen  Act,  the  ability  to  develop  performance  and  cost  metrics,  and  simple  program 
management.  The  Clinger-Cohen  Act  of  1996  requires  that  a  baseline  be  established  in 
order  measure  the  difference  that  any  changes  to  the  system  would  make  and  whether  or 
not  those  changes  are  justified,  based  on  a  cost/benefit  analysis. 

The  Joint  Staff  is  currently  in  the  process  of  establishing  a  baseline  for  GCCS.  This 
initial  effort  is  looking  primarily  at  system  (e.g.,  how  fast  does  GCCS  process)  and 
functional  (e.g.,  how  fast  can  I  do  this  task  on  GCCS)  baselining.  Eventually,  all  aspects  of 
the  program  should  be  baselined,  including  technical  and  architectural  baselines,  a  cost 
baseline,  etc. 

There  has  been  general  agreement  across  the  community  that  GCCS(3.0)  will  be 
the  system  baseline  against  which  changes  will  be  measured. 

3.  Testing  and  Fielding 

Lesson  5:  Testing  needs  to  continue  to  adapt  to  evolutionary  acquisition.  The  GCCS 
testing  approach  needs  to  be  codified  in  a  “ capstone  ”  Test  and  Evaluation  Master  Plan. 

As  described  earlier,  the  views  of  testers  and  developers  have  evolved  as  they  have 
learned  that  significant  issues  can  arise  in  fielding  new  versions  of  GCCS  that  simply  could 
not  be  identified  in  laboratory  testing.  These  result  from  many  factors,  including  the 
interaction  of  GCCS  software  with  both  local  and  wide  area  networks,  or  with  local 
UNIX  configurations.  It  is  now  generally  accepted  that  field  testing  is  needed  before 
entering  final  operational  testing.  As  a  result,  the  community  has  developed  the  concept  of 
“Modified  Development  Testing”  for  GCCS(3.0).  MDT  entails  a  phased  sequence  of 
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contractor,  DISA  integration  laboratory,  and  field  tests  at  operational  sites.  It  thus 
incorporates  field  testing  as  part  of  the  development  testing  process. 

MDT  has  received  significant  praise  throughout  the  GCCS  community.  This 
approach  has  increased  confidence  that  GCCS(3.0)  can  be  installed  and  operated 
successfully  in  the  field.  This  approach  should  also  reduce  operational  testing  problems, 
and  has  provided  the  field  activities  with  a  preview  of  the  applications,  which  will 
contribute  to  improvements  in  training,  operations,  and  support. 

The  MDT  process  for  GCCS(3.0)  has  not  been  perfect.  Commands  using  Hewlett- 
Packard  hardware  experienced  significant  delays  in  installing  the  software.  Other 
Commands  experienced  database  problems,  and  were  unable  to  perform  many  of  the  tests. 
And  in  every  case,  the  tests  were  performed  on  discrete  test  networks,  which  may  not 
reveal  some  of  the  software-network  interaction  problems  that  plagued  earlier  versions 
when  they  were  fielded. 

There  is  general  agreement  that  a  “capstone”  Test  and  Evaluation  Master  Plan 
(TEMP)  is  needed  to  lay  out  the  strategy  and  approach  for  GCCS  testing.  This  plan  can 
describe  modified  development  testing  and  also  how  performance  requirements  and 
performance  measurement  techniques  are  employed  in  the  testing. 

Lesson  6:  JOPES  GSPRs  need  to  be  fixed  concurrent  with  JOPES  business  process 
reengineering. 

JOPES  has  served  as  a  constant  source  of  irritation  for  the  GCCS  community. 
Promised  gains  from  the  transition  from  WWMCCS  and  subsequent  GCCS  releases  did 
not  materialize;  additional  problems  arose  from  the  transition,  including  database 
synchronization,  slow  system  response,  breakdowns,  and  a  legion  of  GSPRs;  the  JOPES 
user  community  is  dissatisfied;  and  too  often  the  health  of  JOPES  has  been  confused  with 
the  health  of  GCCS.  There  are  two  essential  problems  with  JOPES. 

The  first  and  most  important,  is  that  the  processes  underlying  JOPES  are  in  need 
of  major  revision.  The  way  the  data  are  collected,  stored,  manipulated,  and  presented  is  no 
longer  adequate.  For  example,  SORTS  takes  generic  unit  data  and  provides  the  basis  for 
building  a  TPFDD  (Time  Phased  Force  and  Deployment  Data).  JOPES  planners  know  that 
these  plain  vanilla  units  rarely  exist  in  the  real  world,  yet  they  are  forced  to  make  their 
plans  based  on  exactly  this  type  of  generic  data.  SORTS  should  be  allowed  to  compensate 
for  dissimilar  unit  types.  This  is  but  one  example  of  many.  These  process  faults  are  not  an 


artifact  of  GCCS,  they  were  also  found  under  WWMCCS.  They  have,  however,  left 
JOPES  increasingly  maladapted  for  current  planning  conditions. 

The  second  problem  is  largely  a  result  of  the  transition  to  GCCS  from  WWMCCS. 
Specifically,  hundreds  of  GSPRs  have  arisen,  and  remain  unresolved  despite  repeated 
releases  of  new  versions  of  GCCS.17  A  significant  number  of  these  are  priority  one 
GSPRs,  which  essentially  means  that  the  particular  piece  of  software  is  incapable  of 
performing  its  mission,  although  the  net  effect  of  these  GSPRs  is  unclear.  Nonetheless,  the 
transition  has  not  been  and  continues  to  be  an  uncomfortable  passage. 

These  twin  difficulties  need  to  be  addressed  in  tandem,  much  as  a  bleeding  patient 
(GSPRs)  must  survive  long  enough  to  make  it  into  surgery  (JOPES  Business  Process 
Reengineering).  Both  areas  are  making  progress,  but  a  concerted  effort  needs  to  be  made 
to  ensure  that  the  current  form  of  process  reengineering  doesn’t  fail  as  so  many  past 
attempts  have. 

4.  Operations  and  Support 

Lesson  7:  The  GCCS  community  needs  a  configuration  management  system  appropriate 
to  facilitate  interoperability,  security,  and  manageability  in  a  commercial,  client-sender 
environment. 

One  concern  expressed  by  the  community  is  the  lack  of  configuration  management. 
Configuration  management,  of  which  there  are  many  types  (e  g.,  operational,  system, 
technical,  etc.)  essentially  refers  to  knowing  what  you  have  and  how  it  relates  to  the  other 
pieces  in  the  system.  Although  modern  systems  are  forgiving  in  how  they  are  set  up,  they 
will  be  less  stable,  more  vulnerable  to  attack,  more  costly,  and  not  run  as  well,  if  done 
without  configuration  management.  Two  significant  difficulties  have  been  encountered  by 
the  GCCS  community. 

The  first  is  in  coordinating  the  different  users,  a  particularly  challenging  task  in  a 
rapidly  evolving  distributed  computing  environment  with  hundreds  of  sites  and  thousands 
of  terminals.  Knowledge  about  any  particular  site,  while  clearly  known  to  that  site,  often 
appears  to  be  incorrect  or  absent.  Two  solutions  present  themselves.  The  first  solution  is 
to  introduce  and/or  broaden  the  use  of  automatic  and  remote  system  interrogation 
programs  to  define  the  system,  an  act  which  is  already  happening  across  a  broad  swath  of 
the  community.  The  second  solution  is  simply  to  improve  the  coordination  between  the 

1  The  definition  of  what  constitutes  a  GSPR  and  what  level  of  priority  it  constitutes  is  unclear,  especially 
in  a  distributed  computing  environment  such  as  GCCS. 
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field  and  headquarters,  which,  based  on  the  interviews  in  the  field,  appears  to  be  lacking. 
Clearly  delineating  roles  and  responsibilities  would  aid  in  improving  this  coordination. 

A  second  problem  is  the  introduction  of  software  modifications  or  new 
applications  at  the  local  level  without  prior  approval  and  testing  by  DISA.  This  potentially 
leads  to  security  and  compatibility  problems.  This  type  of  practice  has  bedeviled  operators 
of  large  networks  since  their  inception,  and  is  not  unique  to  GCCS.  Given  the  unlikelihood 
of  stopping  such  practices,  and  the  desire  to  keep  the  system  responsive  to  unique  local 
needs,  ground  rules  should  be  established  which  allow  for  local  modifications  within  limits 
proscribed  by  a  central  authority,  DISA.  The  Joint  Staff  should  also  play  a  role  in  ensuring 
some  form  of  system  administration  from  the  center,  while  retaining  local  autonomy. 

Lesson  8:  Additional  personnel  need  to  be  added  to  the  DISA  PM’s  office. 

The  ability  of  the  DISA  technical  program  manager  for  GCCS  to  manage  the 
program  is  hampered  by  staffing  problems  in  the  form  of  unfilled  billets  and  high  staff 
turnover.  At  the  time  the  PM  was  interviewed,  it  was  learned  that  manning  was  at 
approximately  50  percent  (7  of  14  billets  filled).  In  addition,  a  high-turnover  rate,  due  in 
part  to  military  rotation  policies,  harms  the  development  of  institutional  expertise  and 
memory. 

These  facts,  coupled  with  a  perception  in  the  community  that  the  PM’s  office  is 
understaffed,  and  the  recommendation  in  this  report  for  additional  duties  to  be  given  to  the 
PM’s  office,  call  for  an  increase  in  staffing.  Although  this  study  does  not  attempt  to 
quantify  the  level  of  additional  staffing  beyond  a  placeholder  level  or  two  or  three 
additional  person-years,  it  should  serve  as  a  basis  for  the  PM’s  office  to  review  staffing 
levels  and  request  additional  resources  as  necessary. 

Lesson  9:  Training  needs  to  be  improved. 

GCCS  training  has  consistently  lagged  fielding  by  many  months.  This  possibly  is 
due  in  part  to  the  way  in  which  IT  technology,  and  software  in  particular,  is  treated,  not 
just  by  DoD  but  by  society  writ  large.  Typically,  software  is  fielded  without  training,  and 
this  is  accepted  as  normal  practice.  How  many  of  us  have  received  the  latest  Microsoft  or 
Oracle  software  release,  with  zero  training,  yet  we  are  expected  to  immediately  make  use 
of  it.  Although  the  more  complex  the  system,  the  less  prevalent  this  dynamic  becomes,  it 
still  may  affect  attitudes  towards  training,  even  if  subtle. 


A  second  reason  training  has  lagged  is  that  GCCS  has  not  yet  developed  a 
community  of  trained  personnel  with  strong  institutional  support,  as  JOPES  did.  Training 
is  fragmented  and/or  non-standardized,  with  different  offices  teaching  different  pieces  of 
GCCS,  as  opposed  to  the  more  holistic  approach  taken  by  JOPES;  classroom  training  has 
been  criticized  as  lacking  teachers  with  operational  experience  or  live  data  feeds,  for 
example;  software  documentation  is  absent  or  inadequate;  self-paced  and  distance  learning 
is  largely  absent;  and  the  Commander  has  no  ready  means  of  identifying  who  on  the  staff 
has  had  GCCS  training. 

To  remedy  this  situation,  it  is  recommended  that  classroom  training  be 
supplemented  with  distance  learning  and  self-paced  learning  opportunities.  Travel  to  the 
classroom  is  often  costly,  time  consuming,  and  not  reactive  to  immediate  needs.  Distance 
learning  is  less  expensive  and  quicker,  while  self-paced  training  and  help  features18  allow 
the  user  to  proceed  at  one’s  own  pace.  Neither,  however,  is  a  substitute  for  the  classroom. 
In  addition,  the  commander  should  have  the  ability  to  quickly  identify  who  has  been 
trained  on  GCCS,  e  g,  a  note  in  the  personnel  file,  a  centralized  database,  etc. 

Although  beyond  the  scope  of  this  study,  additional  thought  should  be  given  to 
creating  a  central  training  location/office  similar  to  the  JOPES  Training  Office. 

E.  CONCLUDING  REMARKS 

Although  the  concept  of  evolutionary  acquisition  is  not  new,  the  Global  Command 
and  Control  System  represents  in  scope  the  most  significant  program  to  date  in  which 
DoD  has  attempted  to  implement  this  approach.  It  may  be  fairly  termed  a  success.  Major 
new  capabilities  have  been  gained  through  an  acquisition  process  which  has  been  flexible 
enough  to  meet  rapidly  changing  user  requirements  and  to  incorporate  new  technology. 
On  a  more  cautionary  note,  however,  the  perils  of  having  insufficient  process  were  evident 
in  the  early  days  of  GCCS.  Insufficient  process  led  to  inadequate  testing,  program  drift, 
and  still  indeterminate  costs,  among  other  ills.  The  pendulum  has  fortunately  once  more 
swung  back  towards  process,  although  process  that  is  flexible  yet  substantive. 
Evolutionary  acquisition  does  not  obviate  the  need  for  a  roadmap,  for  example,  but  rather 
reinforces  the  need  as  program  and  acquisition  processes  become  more  flexible.  Flexibility 
without  form  equals  chaos.  The  managers  of  future  C2  programs  would  do  well  to  heed 
the  lessons  learned  by  the  GCCS  community  when  weighing  the  merits  of  a  roadmap,  a 

ls  Examples  of  self-paced  training  might  include  CD-ROMs,  manuals,  videos,  etc.  A  help  feature  could 
be  something  as  simple  as  a  pull-down  menu,  much  as  is  found  in  Microsoft  applications. 

22 


requirements  process,  configuration  management,  or  other  acquisition  processes  currently 
under  review  by  the  acquisition  community. 
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